Conversation
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
How to use the Graphite Merge QueueAdd the label merge-ready to this PR to add it to the merge queue. You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
9362d63 to
75a71f2
Compare
0c61270 to
5f45183
Compare
75a71f2 to
d329051
Compare
d329051 to
f5e580a
Compare
5f45183 to
06a3624
Compare
f5e580a to
a5c74d3
Compare
06a3624 to
d112b72
Compare
|
Addressed both |
a5c74d3 to
3eeb7cf
Compare
| if let Some(parent) = args.proof_path.parent() | ||
| && !parent.as_os_str().is_empty() | ||
| { | ||
| fs::create_dir_all(parent) | ||
| .with_context(|| format!("Failed to create parent directory {}", parent.display()))?; | ||
| } |
There was a problem hiding this comment.
The parent.as_os_str().is_empty() check is unnecessary here. When Path::parent() returns Some(parent), the parent path is never empty - it would return None for a path with no parent component. The condition can be simplified to:
if let Some(parent) = args.proof_path.parent() {
fs::create_dir_all(parent)
.with_context(|| format!("Failed to create parent directory {}", parent.display()))?;
}This maintains the same behavior while removing the redundant check.
| if let Some(parent) = args.proof_path.parent() | |
| && !parent.as_os_str().is_empty() | |
| { | |
| fs::create_dir_all(parent) | |
| .with_context(|| format!("Failed to create parent directory {}", parent.display()))?; | |
| } | |
| if let Some(parent) = args.proof_path.parent() | |
| { | |
| fs::create_dir_all(parent) | |
| .with_context(|| format!("Failed to create parent directory {}", parent.display()))?; | |
| } |
Spotted by Diamond
Is this helpful? React 👍 or 👎 to let us know.
3eeb7cf to
dfbed87
Compare
d112b72 to
5886785
Compare
Merge activity
|
### TL;DR
Added a standalone prover binary example that can generate proofs from serialized constraint systems and witnesses.
### What changed?
- Added a new `prover` example binary that reads a constraint system and witness data from disk and produces a serialized proof
- Implemented a `From<ValuesData<'a>>` trait for `Vec<Word>` to simplify conversion of witness data
- Updated the examples README with documentation for the new prover binary, including usage instructions
- Added the binary to the examples crate manifest
### How to test?
1. Generate artifacts from an example circuit:
```
cargo run --release --example sha256 -- save \
--cs-path out/sha256/cs.bin \
--pub-witness-path out/sha256/public.bin \
--non-pub-data-path out/sha256/non_public.bin
```
1. Produce a proof using the new prover binary:
```
cargo run --release --example prover -- \
--cs-path out/sha256/cs.bin \
--pub-witness-path out/sha256/public.bin \
--non-pub-data-path out/sha256/non_public.bin \
--proof-path out/sha256/proof.bin \
--log-inv-rate 1
```
### Why make this change?
This change enables cross-host proof generation pipelines by providing a standalone binary that can generate proofs from serialized inputs. This is useful for scenarios where the constraint system is generated on one machine but the proof needs to be generated on another, potentially more powerful machine optimized for proving.
### TL;DR
Added a standalone prover binary example that can generate proofs from serialized constraint systems and witnesses.
### What changed?
- Added a new `prover` example binary that reads a constraint system and witness data from disk and produces a serialized proof
- Implemented a `From<ValuesData<'a>>` trait for `Vec<Word>` to simplify conversion of witness data
- Updated the examples README with documentation for the new prover binary, including usage instructions
- Added the binary to the examples crate manifest
### How to test?
1. Generate artifacts from an example circuit:
```
cargo run --release --example sha256 -- save \
--cs-path out/sha256/cs.bin \
--pub-witness-path out/sha256/public.bin \
--non-pub-data-path out/sha256/non_public.bin
```
1. Produce a proof using the new prover binary:
```
cargo run --release --example prover -- \
--cs-path out/sha256/cs.bin \
--pub-witness-path out/sha256/public.bin \
--non-pub-data-path out/sha256/non_public.bin \
--proof-path out/sha256/proof.bin \
--log-inv-rate 1
```
### Why make this change?
This change enables cross-host proof generation pipelines by providing a standalone binary that can generate proofs from serialized inputs. This is useful for scenarios where the constraint system is generated on one machine but the proof needs to be generated on another, potentially more powerful machine optimized for proving.

TL;DR
Added a standalone prover binary example that can generate proofs from serialized constraint systems and witnesses.
What changed?
proverexample binary that reads a constraint system and witness data from disk and produces a serialized proofFrom<ValuesData<'a>>trait forVec<Word>to simplify conversion of witness dataHow to test?
Why make this change?
This change enables cross-host proof generation pipelines by providing a standalone binary that can generate proofs from serialized inputs. This is useful for scenarios where the constraint system is generated on one machine but the proof needs to be generated on another, potentially more powerful machine optimized for proving.